This disclosure is based upon, and claims priority from, French patent application No. 9907239, filed Jun. 4, 1999, the contents of which are incorporated herein by reference.
The invention relates to smart cards, also referred to as microprocessor cards, and more generally to microprocessor-based programmable open data processing means which are capable of being loaded with applications written in advanced programming languages. The invention is more particularly directed towards the fact that these different languages are heterogeneous in nature, which does not allow an application written in one particular language to be executed by any arbitrary programmable data processing means.
The invention is consequently also directed towards the openness of data processing means. The invention relates to the interoperability of applications written for programmable data processing means, such as the JAVA Card and other operating systems for smart cards. Interoperability is accompanied by requirements in terms of security.
In the field of programmable smart cards, each programming source language used for writing an application intended to be loaded into a card is strongly linked to a particular execution medium generally having a software nature, such as a virtual machine, but also having a hardware nature, e.g. a microprocessor.
In order to be able to load a program into a smart card, the program written in a given source language is compiled, and then loaded into a smart card that is intended to receive programs written in the given source language. The card receives the compiled program and executes it by means of an execution medium specially dedicated to the execution of programs initially written in the given source language.
As shown in FIG. 1, smart cards Cn each contain a respective execution medium SEn different from those SE1 to SEN of other smart cards C1 to CN. The integer n, where 1xe2x89xa6nxe2x89xa6N, designates a predetermined language from a number of source languages LS1 to LSN. Each card Cn can execute application programs Pn only if they are programmed in the respective source language LSn. Prior to compilation of the program to be loaded, the latter undergoes a code verification in order to check that the program to be loaded does not infringe security features provided by the execution medium SEn associated with the source language LSn.
In fact, in such a set of cards, a program Pn developed in a given source language LSn is intimately linked to the target execution medium SEn on the grounds that:
1) the data structures and the operations provided by the source language LSn are specialized in order to be compiled to a representation optimized in size and speed for the execution medium SEn dedicated to the source language LSn;
2) programming libraries BPn provided with the source language LSn are generally correlated with the source language and optimized for the execution medium SEn dedicated to the source language; and
3) the verification of the program Pn before it is loaded into a card Cn is intimately linked to the security features provided by the target execution medium SEn.
This strong link between a source language LSn and its execution medium SEn is expressed in a verification, compilation and loading chain CVCCn. This chain manages a transformation of a program Pn written in a high-level source language into a compact form ready to be executed efficiently by the execution medium SEn dedicated to the source language LSn.
The general problem at the heart of the invention is the linking of programs written in any one of the different source languages LS1 to LSN with different execution media SE1 to SEM, M being any integer equal to or different from the integer N. This general problem can be broken down into the following three sub-problems.
According to the first sub-problem SP1, it is desirable, for example, to make a program P written with a source language LSn run on an execution medium SEm dedicated to a given source language LSm, with the index m between 1 and M.
The second sub-problem SP2 consists in loading programs P1 to PN, written respectively with different source languages LS1 to LSN, into a common execution medium SEm capable of providing these different programs with an environment which is efficient in terms of memory size, execution speed, their programming libraries BP1 to BPM and their security features.
The third sub-problem SP3 aims to make different programs P1 to PN, written respectively in different source languages LS1 to LSN, coexist within a common execution medium SEm. For the third sub-problem, the security of the programs P1 to PN originating from different programming environments and placed in one and the same physical medium should be dealt with.
In order to solve the three sub-problems SP1, SP2 and SP3, which amounts to solving the interoperability of different applications written for example for programmable smart cards with preservation of security and protection and interaction mechanisms, persons skilled in the art could envisage the following three categories of solution which are, however, not entirely satisfactory.
The first solution, the simplest and the most used, consists in rewriting a program Pn, written in a source language LSn dedicated to an execution medium SEn installed in a smart card Cn, as programs Pn1 and PnM written respectively for example in source languages LS1 and LSM dedicated to execution media SE1 and SEM installed in smart cards C1 and CM, as indicated by write operations W1 and WM in FIG. 2.
The first solution has as the main drawback an extensive and tedious manual task for a programmer, consisting in rewriting the algorithm of the program Pn as the programs Pn1, PnM which must be adapted to the different data structures and programming libraries BP1, BPM for the new source languages LS1, LSM. Furthermore, the security mechanisms provided by each of the new execution media SE1 and SEM require that the code of the rewritten program Pn1, PnM be recertified.
The first solution deals solely with the sub-problem SP1 and thus solves only very partially the problem of program interoperability. Furthermore, if another source language associated with an execution medium other than the execution media SE1, SEn and SEM appears in a new card, it is necessary to deal again with all the old programs written in the initial source language LSn in order to rewrite them with the other source language.
The second solution includes a cross-compilation. With reference to FIG. 3, let there be for example two programs P1 and P2 which are written in respective source languages LS1 and LS2 to which are initially dedicated two respective execution media SE1 and SE2 in two smart cards C1 and C2 after having undergone compilations in verification, compilation and loading chains CVCC1 and CVCC2, they can each be executed conventionally in the execution media SE1 and SE2. However, the programs P1 and P2 must be executed in the media SE2 and SE1 respectively, and also both of them in a third execution medium SE3 contained in a third smart card C3 and dedicated to a third source language LS3.
In order to execute the program P1, or P2, in target execution media SE2 and SE3, or SE1 and SE3, other than the execution medium dedicated to the initial source language LS1, or LS2, the program P1, or P2, undergoes compilations in additional verification, compilation and loading chains CVCC21 and CVCC31, or CVCC12 and CVCC32.
Compared with the first solution, the second solution no longer necessitates, on the part of a programmer, manual rewriting of the programs, but requires many verification, compilation and loading chains CVCC12, CVCC21, CVCC31, CVCC32 to be made available. More generally, for N source languages LS1 to LSN and M execution media SE1 to SEM, N*M verification, compilation and loading chains are necessary. These chains necessitate, by their number and complexity, a considerable hardware, software and human investment.
Besides this major drawback, the second solution has the following drawbacks:
poor performance as regards memory size and execution speed of the programs thus generated, the execution media in which they are executed not being a priori suitably adapted to the data structures, operations and programming libraries of the source languages LS1 and LS2 used for writing these programs;
production of verification, compilation and loading chains equal in number to the existing target execution media SE1 to SEM when a new source language appears, and conversely equal in number to the existing source languages LS1 to LSN when a new execution medium appears;
for the deployment of programs, prior loading of all the downloading stations with the programs equipped with the compiled and certified codes for the different execution media SE1 to SEM, which makes the second solution still more complex and costly.
The second solution deals solely with the sub-problem SP1 but in an automated manner compared with the first solution, and thus solves only very partially the problem of interoperability. Furthermore, if another source language associated with an execution medium other than the execution media SE1 to SEM appears in a new card, it is necessary to pass all the initial programs P1 to PN through new verification, compilation and loading chains producing certified codes for the other execution medium.
The third solution proposes smart cards CP which each contain a number of execution media, for example three execution media SE1, SE2 and SE3, as shown in FIG. 4. Thus, programs P1, P2 and P3 written respectively with different source languages LS1, LS2 and LS3 can be loaded into the card CP through the respective verification, compilation and loading chains CVCC1, CVCC2 and CVCC3. The card CP provides each program P1, P2, P3 with exactly the same functionalities as if it were loaded individually on a card having only the execution medium SE1, SE2, SE3 dedicated to the respective source language LS1, LS2, LS3.
The third solution retains advantageously the verification, compilation and loading chains CVCC1, CVCC2 and CVCC3 respectively associated with the source languages LS1, LS2 and LS3 and also allows the sub-problem SP2 to be solved.
Nevertheless, the third solution has the major drawback of being all the more impracticable at present since the number of different execution media to be installed in the card, each representing a significant amount of code, is large. This major disadvantage is also present in VVM architectures of the type described in the publication entitled xe2x80x9cVirtual Virtual Machinesxe2x80x9d by Bertil Foliot and Ian Piumarta (September 1997) or in the publication entitled xe2x80x9cA Dynamically Configurable Multi-language Execution Platformxe2x80x9d of the same authors (1998). In this type of architecture, several execution support platforms are present in memory. These execution supports function as an additional layer of abstraction of the low level system primitives. However, the memory necessary to support this type of solution is not currently practical in a smart card. Even if it were available, it would be more useful to employ the memory to store additional data and programs, for example, rather than multiple execution media.
The main objective of the invention is to provide a method for automatically executing a number of programs written in different source languages in a single execution medium, without constraining a programmer to a single source language for a respective execution medium type. This main objective amounts to solving the three sub-problems defined above, SP1, SP2 and SP3, i.e. the interoperability of programs in different source languages, which none of the three solutions presented above solves completely.
To that end, the method of migration of a number of programs, written respectively in source languages to which respective execution media are dedicated, to a data processing means, comprises the steps of:
compiling each program into a respective program expressed in an intermediate language representing a minimum subset of the source languages,
providing, in the data processing means, a predetermined execution medium dedicated to the intermediate language, and
loading the respective intermediate language program into the data processing means with a respective programming library adapting the respective source language to the intermediate language in order to execute the intermediate language program in the predetermined execution medium.
The invention is based on the search for an execution medium which is initially the lowest common denominator present in predetermined microprocessor-based data processing means execution media; for example the execution media are contained in known smart cards of different types, i.e. whose programs are written in different source languages. The invention therefore offers the advantages of the third solution presented previously, proposing that the set of all possible execution media be put in one microprocessor-based data processing means. But instead of requiring a considerable, perhaps even unachievable memory size, the invention installs only a reduced execution medium dedicated to a minimum, but flexible, intermediate language in each data processing means, such as a smart card. As such, the intermediate language is not associated with any particular source language, and serves as a base language for serving as a target for a number of source languages. The memory required for installing the intermediate language is thus reduced, and consequently the execution of a program is faster than in the third solution proposed above.
The invention thus uses the combination of:
an intermediate language capable of representing both the programs written in different languages and the specific security features and programming libraries necessary for their correct operation, and
an execution medium dedicated to the intermediate language, but capable of being reconfigured in order to best adapt to the requirements of each language, both in terms of working environment and in terms of checking the security of the applications.
According to a variant of the invention, the compiling step can comprise the steps of:
compiling the program into a compiled program in a machine language to which the respective execution medium is dedicated, and
converting the compiled program into the respective program expressed in intermediate language.
This variant can be of interest for a developer of a program from the compiled result of a program for producing the code in intermediate language. The tool which allows this operation is a converter. It replaces the instructions of the respective execution medium associated with the source language with operations written in intermediate language.
According to another aspect of the invention, the method can comprise a step, before the loading step, for extracting validation information from the respective program in intermediate language, and a step, after the loading step, for verifying the extracted validation information in the predetermined execution medium.
According to another variant, the predetermined execution medium can be similar to one of the execution media. Although overall less advantageous than the basic embodiment of the invention, this variant can be of interest when the source languages are languages which have undergone similar developments and modifications.
Preferably, the intermediate language is extendable, while the predetermined execution medium is extendable or not extendable. At least one of the source languages and the intermediate language are advantageously object-oriented languages.
In practice, the method can comprise a step of reading of the characteristics of the predetermined execution medium by a server which then performs the compiling step.
The data processing means can be, for example, a smart card. The smart card can be a subscriber identity card included in a mobile radiotelephone terminal.